JAWS-UGコンテナ支部 #3に参加してきた #jawsug #jawsug_ct

JAWS-UGコンテナ支部 #3に参加してきた #jawsug #jawsug_ct

Clock Icon2015.11.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

今日はJAWS-UGコンテナ支部 #3に参加してきました!

場所はDeNAさんのセミナールーム。いつ来ても立派なお部屋です。

12276812_490060791175793_2069202165_n

レポート

Amazon EC2 Container Service by AWSJ 岩永亮介さん (@riywo)

Amazon ECSデモ

 node.jsで書かれたGeneratorがダミーのアクセスログを作成、Kinesisに投入
 Pythonで書かれたConsumerがKinesisからログを取得、AWS IoTにMQTTでPublish
 node.jsで書いたダッシュボードでログを表示

IMG_3497

DevOpsのライフサイクル

 開発、ビルド、テスト、プロダクション環境へのリリース。
 裏でもう1つやらなくてはいけないことがある。サーバの構築。環境ごとの設定。
  アプリケーションとは別にメンテし続けなくてはいけないのが結構辛い。
 Dockerになると?アプリケーション、サーバ、環境設定が一まとめになっている。
  Dockerの中のプロビジョニングはShellでもいい。ほとんど一回しか流さない。
  一回プロビジョニングしたらあとはテスト環境にもプロダクション環境に巻くだけ。
 DevOpsの流れが変わる可能性があるのがDocker。

Amazon ECS

 Containerをただ起動するだけなら超簡単。管理する必要が無い。
 ECSを使えば?
  ホストとなるEC2の利用を効率的に行える。
  ホストEC2のインスタンスタイプを分散(EC2 Spot Fleet)
  Cluster管理、リソースの状況を監視し、適切に配置

Amazon ECS Update

 Amazon EC2 Container Registory
  もうちょっとでリリースされる、ご期待ください。
 AZを意識したスケジューリング
  フェールセーフな作りができる
 ECS CLI
  Docker Composeと連携、yamlで制御
 Docker Containerの設定オプションを改善
 CloudWatchメトリクスの追加

まとめ

 DevOpsの改善が一番大きなメリット
 クラスタ管理をECSにぶん投げると、Dockerのコンテナ管理が非常に簡単
 ECRがリリースされるとレジストリ管理を考えなくて良くなる  

Next FRESH! Applications with Amazon ECS by 株式会社サイバーエージェント @stormcat24さん

AmebaFRESH!

 生放送動画配信プラットフォーム
 12月に一般公開予定、現在クローズド公開中
 スマホナイズドされたUI、オシャレなニコ生を目指している
 Amazon ECSで全て稼働している
 4月からプロジェクト開始、メンバー約30名
 配信はRTMP Publishing、視聴側はHLS
 サーバサイドは全てAWS。Go1.5 + Docker 1.9.0。
 マイクロサービスアプローチを取っている。APIはRESTful(goji)

アーキテクチャー

 目指していること
  極力メンテを入れず運用していくことを目標
   24時間何かしら配信があるような状況に持っていきたい。
   ゼロダウンタイムのためのBlue-Green Devployment。
   インフラは更新せず入れ替える。
  素早く頻繁にどんどんリリースしていきたい
   システムは疎結合、マイクロサービス。
   何が使いやすいか?出した答えがコンテナ。
 マイクロサービス
  特定の開発言語に依存しない。使い続けると飽きる。
   来年Elixirとかやるかもしれないし、Javaに戻るかもしれないし...
   エンジニアのモチベーションを維持する一つの方法がマイクロサービス化かなと思っている。
  通信プロトコル
   RESTFul API。HTTP。
   ELBがHTTPSをサポートしていないのでgRPCはまだ対応していない
  マイクロサービスの粒度
   タイムラインとか、システム的なドメインで切っている。
   あとから切り直すのも全然ありかなと思っている。
 インフラはECS
  ちょうど検証中に東京リージョンに来た。
  コンテナ構成管理とスケジュールがあれば運用できると判断。
  他にもAWSで使いたいサービスがあった。LambdaとかAuroraとか。
 実際どうやって作っているか。基本方針
  マイクロサービスごとにTask Definition
  1ECS Cluseterに1Service
  1Clusterには1つのAutoScaling Groupが紐付いている
   動画配信サーバは特殊なので例外
 Taskの構成方針
  Dockerを使う上で一番気をつけなきゃいけないのはログ。消失しないように。
   td-agentでログを転送。各コンテナのログは、コンテナが所属するホストに吐く。
   td-agentがホストのログディレクトリをマウントして、他の場所に転送
   Docker 1.8からサポートされたlogging driverを使えばtd-agentがいらなくなる
    が、まだ導入していない
  Internal Serviceであってもログを出すのが楽なので必ずNginxを通している
 1Cluster=1Serviceのデメリット
  リソース効率的にはいまいち。1クラスターに複数のサービスを任せるのがベスト
  リソース効率が悪いので、インスタンス数は増える傾向にある。
  開発環境ではt2.microのような小さいインスタンスを有効活用。
   nanoインスタンスが出てくると有効活用できそう。
 1Cluster=1Serviceにしている理由
  Dockerビギナーにとって視覚的に分かりやすい
  サービス単位にIAM Roleで制御したいが、IAM RoleはEC2にしか割り当てられない
  サービス単位でのSecurity Group→ELBを活用すればクリアできる。

Blue Green Deployment

 2AutoScalingパターン
  Blue、GreeのClusterを作成。
  それぞれがAutoScaling Groupに所属。
  AutoScaling Group単位でELBの切り替えを行う。
  特徴。とても安全にデプロイできる。ロールバックも楽。
   ただしデプロイ前にStandbyのウォームアップが必要。
  2系統あるのでコストが嵩む。不要になったGroupは落とすなどで対処。

Diet Docker Image

 イメージは小さいほど良い。Build時間もCI時間も下がる。
 Registoryからのダウンロード時間も短くなる。
 AutoScalingで立ち上がるサービスの起動も早くなる。
 dokcer hub
  たくさん公式イメージがあるが、大きいものがたくさんある。
  Dockerを運用する上ではボトルネックになりがち。1GB超えるとデブ。
 不要なものは削除
  対処の積み重ね。不要なファイルの削除、ビルドで生じたゴミを消す。
  Data Volumeを使ってホストのファイルシステムを利用→ポータビリティが落ちる
 RUNの回数を減らす
  Dockerは差分ビルドなので、RUNの分だけイメージのレイヤーが増える。
  なるべく&&でチェインして、RUNの回数を減らすのが良い。
  長いdocker buildで途中でこけるとRUNの頭から始まる→辛い。
  RUNを1回でやるのがスタンダードなのかな、と思う。
 軽量イメージを使う
  オフィシャルでもslimイメージが用意され始めている
  busybox、とても軽い
   ポータビリティは高い
   アプリケーションが求める環境を構築する難易度が高くなる
 減量による弊害
  x509問題、軽量化し過ぎて発生
   コンテナからHTTPS通信ができなくなる
  外部ツールに依存しすぎていると辛い
 ベースイメージの作成
  aptなどパッケージアップデートは時間がかかる
   たまにaptが調子悪くてbuildが失敗したりする
  アップデート済みのイメージを作成しておく

ローカル開発はどうやっているか

 docker-machineとVirtualBox
 docker-compose
 docker-machine
  バックエンドにDockerホストを構築する
  あたかもローカルにDocker環境があるかのように操作ができる
  Vagrantは捨てた。Dockerに比べると起動も遅い、プロビジョニングも辛い。使い捨てコストが高い。
  アプリケーション、ミドルウェアを全部ローカルで確認できる
  nginxへの通信などはVirtualBoxのポートフォワードを使う。
 ローカルをフルでDockerにするとマシンリソースが必要。
  ローカルPCをメモリ16GBに変更。コンテナをいっぱい立ち上げると辛い。
  コンテナを立ち上げてもTwitterができるように。
 docker-compose
  Docker Toolboxの一部。元々figと言われていた。
  DockerコンテナをYAMLで管理。
  ローカルのデータストアもDockerでやっている。
   MySQLやRedisなどをdocker-composeで立ち上げ。一瞬で手に入る。
 DBのマイグレーション。
  環境があってもデータ不備があると意味が無い。
  FRESH!ではgoのgooseを使っている。SQLを時系列で並べて適用。
   SQLじゃなくてGoでも書ける。
 ecs-formation
  docker-composeのように、YAMLでコンテナを管理。
  当時はecs-cliが無かったので自作。aws-sdk-goを利用。
  主な機能。Task Definitionsの更新、クラスタに配置するサービスの更新。Blue-Green Deploymentの実現。   

その他のツール

 AMI
  EC2-Otimized AMI。Docker + ECS Agent。便利だけど社内で面倒見切れなかった。
  自前のUbuntuイメージを作成。
 Private Registory
 CircleCI
  1リポジトリに1Dockerfile。
  インフラ系ミドルウェアは別のリポジトリに。
 Terraform
  インフラ構築のためのオーケストレーションツール
  AWSでのインフラ構築で利用
  EC2、SG、Route53(Internal)、ECS Cluster、AutoScaling Groupの起動構成
  癖のあるツールなので、ELBなど運用によって状態が変わるものには無いていない
  ビルドに時間がかかるRDSやElastiCacheにも向いてい無い
  クリティカルなものは避けている(Route53、IAM)
  tfstateはS3上に保持
  全てを1つのtfstateで管理しない。環境によって分ける。
 Mackerel
  監視は基本的にMackerel。綺麗で見やすい、お気に入り。
  最近Dockerのメトリクスが取れるようになった。

所感

 ECSの進化が早く、ついていくのは大変だが、周辺ツールが充実してきた
 全然運用できるな、という感想
 やりたいと思う人はぜひやってみてほしい

最後に

サイバーエージェントさんの事例は非常に興味深かったです。Imageのダイエット方法など、とても参考になりました。

さて、これからLTタイムですが、僕はビールを飲みながらピザを食べるので特にメモは取りません!楽しみます!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.